The objective of the Project Definition Phase is to create a system design foundation. The goal is then to get information (the big picture) from the client, put it on paper, and then get the client to sign-off the paperwork.
Models will be developed for many characteristics of the system and will address both the contexts in which the system will be used and the components performing functional algorithms for each alternate design of the product system. Sample characteristics that will be modeled are cost (development, production, operational, refinement, retirement); reliability, availability, and supportability; durability; security; safety; key quality, quantity and timeliness aspects of major system outputs. The models for the preferred alternative will be expanded and used to help manage the system throughout its entire life cycle. Many types of system models are used, such as physical analogs, analytic equations, state machines, block diagrams, functional flow diagrams, object-oriented models, computer simulations and mental models.
Systems Engineering is responsible for creating (developing) a product and also creating the processes for producing, deploying, training, refining, and retiring it; these aspects of the product make up its life cycle. So, models should also be constructed for each of these processes. A key process oriented model to be created is the risk model, which identifies risk issues and analyzes those risks to determine which should be costeffectively mitigated and which should not. Development process models allow us, for example, to study scheduling changes, create dynamic PERT charts and perform sensitivity analyses to show the effects of delaying or accelerating certain subprojects. Running the process models reveals bottlenecks and fragmented activities, reduces cost and exposes duplication of effort. Product models help explain the system.
As previously stated, the Systems Engineering Process is not sequential. It is parallel and iterative. The complex interrelationship between creating and improving models throughout the process of developing and selecting alternatives is a good example of the dynamic nature of the systems engineering process.
The Conceptual Diagram provides the client with high-level (single page) functional understanding of a particular system without getting into tedious detail. It is one of the first drawings the client sees. It must, therefore, present the “big picture” clearly enough that fundamental design decisions can be agreed upon. The goal is to create a drawing that quickly conveys how the entire system operates in a way that even moderately technical executives can understand and it must act as a starting point for further technical discussions. It should clearly show features of the system design that require customer consensus. Figure 17 is an example of a relatively complex system (over one hundred drawings) effectively reduced to one page.
Conceptual diagrams provide the client with high level (single page) functional understanding of the system without getting into tedious detail. The goal is to create drawings that quickly convey how the system operates in a way that even moderately technical executives can understand. The Program Flow diagram usually includes both video and audio. Control information is typically left out but can be included on a separate page if the system complexity warrants it. Multiples of same devices do not have to be drawn, but simply indicated by a quantity.
Do I need a Conceptual Flow Diagram? If the system (e.g., video, audio, intercom, sync reference, etc.) can be drawn on a one-page synoptic, the answer is “NO”. Just because a Drawing List Template contains a Conceptual Flow Diagram slot does not mean one must be created. Most systems designed by SIC, however, are not small enough to fit on a one-page synoptic. Therefore, the value added by a Conceptual Diagram can be well worth the time, energy, and expense of its creation. Because SIC projects are designed by engineering teams, creating these diagrams is very useful for generating valuable discussions and brings design issues to light very early in the project design cycle.
So first issue: Creating too many conceptuals. Conceptuals should be generated only for systems that are so complex that they need clarification. Do not create conceptuals for systems that can be easily understood by reading a single synoptic.
Guidelines for creating conceptual diagrams
The program flow diagram is essential. Timing diagrams are done only when the complexity of the project warrants it. The timing diagram shows timing delays through major processing paths. This document is important for timing analog systems and for identifying lump line, field, and frame delays in digital and hybrid analog/digital systems. Delays in the video path must be compensated for in the audio path to maintain lip synchronization. Audio must never lead video in time.
Floor Plans show proposed console and equipment locations within the client’s room specifications. It is very important that room, rack, and console bay names are indicated on the Floor Plans. The client must sign off or modify and sign the drawing. The electrical and lighting plan may be included on the Floor Plan (if not too complex), or they may done on a separate drawing. A scaled building drawing may also be required that contains cable, raceway, and wall penetration information.
Rack and console elevation drawings show where devices will be mounted in consoles and racks. Additionally, they are instrumental in conveying the systems ergonomics to the client’s operations staff.
It is very important that rack elevations indicate the device mnemonic, make, and model. The abbreviation used in the mnemonic should be taken from the client approved abbreviation list. Monitors and waveform monitors need to show the signal that can be selected on each input. Side and rear views of consoles and racks should be provided as necessary. The project Installation Supervisor should be consulted in cases of exceptional density or unusual situations such as trains, trucks, airplanes, etc.. The client must approve these plans before construction can begin.
An Excel rack elevation template is on the network for quick generation of elevations. Drafting prefers hard copy (bigger is better) attached to the drafting request form.